feat(planner): select summary-maintenance lifecycle plans - #318

Stacked on #317.

Why

Legal summary-maintenance alternatives must participate in candidate selection before a post-ASAP DAG is committed. The planner must account for both sides of demand:

• query recurrence determines the expected number and timing of reads;
• data arrival determines the expected number and timing of state updates.

Those quantities change whether rebuilding for every query, retaining shared state, continuously maintaining state, or evaluating the raw expression is cheapest.

Before this PR

The planner could enumerate lifecycle alternatives, but semantic summary candidates were still ranked without their complete build, update, read, retention, and retirement cost. The selected lifecycle and maintenance mode were not materialized as a physical guarantee.

After this PR

Every costable summary candidate receives a horizon-wide summary-maintenance cost before global selection. The selected post-ASAP DAG carries a SummaryMaintenanceLifecycleGuarantee, and materialization can still choose raw KeepPreAsap recomputation when it is no more expensive.

Selection algorithm

Inputs are the existing PlanSpace, the normalized QueryWorkload plus target-to-entry bindings, planning time, optional optimization horizon, runtime lifecycle capabilities, and the existing CostModel.

1. Derive demand per target. PlanSpace propagates effective uses through the DAG and derives a RecurrenceProfile for each target. The lifecycle planner converts the bound workload entries into expected reads, one-time invocations, evaluation rate, fresh update rate, data arrival, and any valid prepared-state window.
2. Enumerate each summary candidate. For every semantic Replacement::Summary candidate, collect each unique reachable SummaryAgg once by Rc identity.
3. Enumerate lifecycle alternatives per state. Consider Ephemeral, Prepared, Shared, and ContinuouslyMaintained. Reject alternatives that violate workload requirements, runtime lifecycle support, summary update/delete capabilities, horizon requirements, or evidence freshness.
4. Compute horizon-wide costs. The CostModel supplies primitive build, per-update maintenance, read, retention-rate, and retirement costs. The planner combines them with expected reads, update rate, and retention duration:
   • ephemeral rebuilds and retires state for every read;
   • prepared state is built before a known one-time execution window;
   • shared state pays one build and retention cost, then serves multiple reads;
   • continuously maintained state additionally pays for every expected update.
     With B = build, M = maintenance/update, Q = summary read, S = retention/second, X = retirement, R = expected reads, U = expected updates, and T = retained seconds, the implemented totals are:
   • ephemeral: R * (B + Q + X);
   • prepared: B + one_time_reads * Q + U * M + T * S + X;
   • shared or continuously maintained: B + R * Q + U * M + T * S + X.
     For data at rest, U * M is zero. Missing inputs remain unknown; they are never interpreted as zero.
5. Make nested summaries executable together. Summary states connected without an intervening readout must use a compatible EvaluationSchedule. For each connected component, compare the total cost under each schedule that every member supports, choose the cheapest common schedule, then choose each member's cheapest lifecycle under that schedule.
6. Rank semantic summary candidates. Sum the selected costs of unique deployments and attach the known total as a CandidateCostOverrides entry. PlanSpace::global_selection_with_candidate_costs uses the cheapest lifecycle-aware summary candidate for that memo group while retaining its existing topological effective-use propagation.
7. Materialize the physical guarantee. Materialize the globally selected DAG and attach lifecycle, SummaryMaintenanceMode, evaluation schedule, and output representation to each deployment.
8. Compare the complete summary plan with raw recomputation. raw_query_recompute_cost * expected_reads is compared with the selected summary deployment total. A known raw cost wins ties and replaces the target with KeepPreAsap.

How this composes with the existing cost planner

This is an additional physical-cost stage, not a replacement cost system:

• Replacement strategies and accuracy/error legality first determine which logical rewrites and summary algorithms are valid candidates.
• Existing sketch sizing and semantic candidate construction still use the same CostModel.
• Existing recurrence-aware CSE planning still provides recurrence profiles and propagates effective consumer counts. It continues to decide share versus recompute for groups that do not receive a lifecycle-cost override. For details, see PR #295, the cost semantics and RecurrenceProfile documentation in recurrence.rs, and the selection code in PlanSpace::global_selection_with_recurrence and decide_group_with_recurrence.
• Lifecycle planning reuses those recurrence profiles and adds complete physical summary-state costs through CandidateCostOverrides.
• If a memo group has no candidate with a known lifecycle total, that group falls back to the existing estimate_cost/CSE ranking path. Within a lifecycle-ranked group, uncosted candidates cannot beat known totals; unknown evidence never becomes an artificial zero.
• The final raw comparison is a whole-target fallback after materialization, rather than another summary lifecycle.

Therefore the flow is:

candidate legality and sizing -> recurrence/effective-use analysis -> lifecycle-aware candidate totals -> global PlanSpace selection -> physical lifecycle guarantee -> raw recomputation fallback.

Verification

• cargo test -p asap-aware-mapping summary_maintenance_lifecycle --no-fail-fast
• cargo clippy -p asap-aware-mapping --all-targets -- -D warnings
• E2E coverage continues in test(planner): cover summary-maintenance lifecycle end to end #319.

Stack

Base: #317. Next: #319.